chore: clarify sort and partition semantics in table schemas - #157
chore: clarify sort and partition semantics in table schemas#157hotdata-automation[bot] wants to merge 1 commit into
Conversation
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| columns: Optional[List[ColumnInfo]] = None | ||
| connection: StrictStr | ||
| last_sync: Optional[StrictStr] = None | ||
| partition_by: List[TablePartitionKey] = Field(description="The table's partition keys, in the order they were declared when the table was created. Empty when the table is not partitioned. A table's storage layout is fixed when the table is created and cannot be changed afterwards, so this is how to confirm a table really was created with the layout that was asked for. The field is always present: an empty array means \"no partitioning declared\", which is not the same as a response that omits the field entirely. Reported for tables in a hotdata-managed database, which are the only ones whose layout is declared here. A table discovered from an external connection always reports an empty array — its layout belongs to the upstream system, so an empty array there means \"not known from here\", not \"confirmed unpartitioned\".") |
There was a problem hiding this comment.
nit: partition_by and sorted_by land as required fields on this response model (no default), so TableInfo.from_dict passes None for them when the key is absent (line 128/130) and model_validate raises. Any API deployment that doesn't yet emit both keys makes the whole information_schema response undeserializable, not just these two attributes empty.
That's the standard generator output for a required array (same shape as InformationSchemaResponse.tables), so nothing to change here — but it means the spec's "always present" guarantee is now load-bearing for this SDK. Worth confirming the server ships both keys for external-connection tables too (where the docs say they're []) before release; the Integration Tests / integration check is the thing that would catch it, and it hadn't reported when this review started. (not blocking)
|
|
||
| ### Changed | ||
|
|
||
| - chore: clarify sort and partition semantics in table schemas |
There was a problem hiding this comment.
super nit: the entry reads as documentation-only, but this change also adds two required fields to TableInfo (partition_by, sorted_by). Users constructing TableInfo directly now need both, and payloads missing them fail validation. The neighbouring feat(tables) entry partly covers the topic, but calling out the TableInfo addition would make the release notes accurate. (not blocking)
Auto-generated from the updated HotData OpenAPI spec.
Source: https://github.com/hotdata-dev/www.hotdata.dev/pull/309